Stockholm den 3 juni 2019 


Vilka standardkrav bör ställas på det finansiella dataflödet 
från transaktion till rapport? 


Hur ser kedjan av dokument ut som ingår i dataflödet för finansiell 
rapportering? 


Transaktion => Kontering => Saldorapport => Slutlig rapport 


Transaktion, kontering och slutlig rapport är ju givna, men varför saldorap- 
port? Alla plattformar för företagens finansiella hantering bygger på att 
kontodata periodvis summeras som saldorapporter. Som sådana skickas 
de bl.a. till revisorer eller redovisningskonsulter och används i företagens 
interna finansiella analys och hantering. Alla plattformar är byggda efter 
den metoden. 


A. Standard för transaktionerna 


Samtliga affärsdokument (från produktkatalog till leveranskvitto) finns alla 
definierade i standarden UBL 2.0 eller UBL 2.1. Av affärsdokumenten är 
t.ex. beställning och faktura dokument som kan skapa transaktioner. Sve- 
faktura är t.ex. en svensk tillämpning under UBL. 


Att skicka transaktioner till myndigheter kräver att transaktionerna är läsbara 
och att de ska kunna signeras. Transaktioner definierade i UBL är så kom- 
plexa att de är svåra att läsa. Av det skälet bör de inte skickas in till myndig- 
heter utan någon form av presentationsformat. En lösning av typ iXBRL (se 
nedan) vore lämplig, men att skapa en standard för att exportera transaktio- 
ner är tveksamt, eftersom sådana dokument innehåller affärshemligheter. 


I Sverige kommer dokumenten enligt offentlighetsprincipen att bli allmänna 
handlingar för vem som helst att hämta ut, om de skickas till en myndighet. 


Utöver detta konteras många affärshändelser som inträffar inom företaget, 
så det är svårt att få en god bild av företaget utifrån transaktionerna utan 
en fullständig kontering. 


Slutsats: Transaktionerna är redan definierade till format, men bör inte 
skickas till en myndighet. 


B. Standardkrav för saldorapporterna och de slutliga rapporterna 


För konteringen har mjukvaruföretagens plattformar var och en sina meta- 
data och sin struktur. De har således vitt skilda format. Här skulle en stan- 
dard tvinga mjukvaruföretagen att göra om sina plattformar fullständigt. 
Vilka standardkrav måste ställas för övriga dokumenttyper utanför transak- 
tionerna och konteringen, alltså för saldorapporterna och de slutliga rappor- 
terna? 
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1. Standarden ska koppla metadata (begrepp) till data. 

2. Standarden ska kunna ha ett schema för sådana kopplingar. 

3. Standarden ska kunna dela upp begrepp i undergrupper (dimensioner). 
4. Standarden ska kunna länka samband mellan olika begrepp (koncept; 
metadata). Ex: För att kunna göra en presentation av en rapport måste 
standarden kunna länka ordning och hierarki för ingående begrepp (koncept; 
metadata). Den måste kunna länka presentationstext till begreppets digitala 
namn. Ex: Till det digitala begreppet "Nettoomsattning" ska kunna kopplas 
"Net sales" i en presentation på engelska eller "Nettoomsättning" på svenska. 
5. Standarden för de rapporter som skickas från företagen till rapportmotta- 
garen ska göras i ett format som kan signeras, dvs som både är läsbart och 
är nedladdningsbart i mottagarens databaser. 


Vilka format för dokumenttyperna saldorapport och rapport är aktuella? 


Comma Separated Values (CSV), Tab Separated Values (TSV) eller Excel 
uppfyller varken punkterna 1, 2, 3, 4 eller 5. 


JSON (Javscript Object Notation) uppfyller punkterna 1 och 3. Standarden 
har för närvarande ett utkast till punkt 2 (schema) och punkt 4 (linkbase), 
men saknar punkt 5. 


XML med ramstandarden XBRL 2.1 och med iXBRL som rapportformat 
uppfyller alla fem punkter. Men uppfyller det även kraven för saldorapporter? 


<?xml versior="1.0"> 
<xbr] ...> 
<lirk schem Ref xlirki type=" simple" 
xlirkihref="http: //taxonomi.xbrl.se/se/fr/k2/..."/> 
<cqontext id="RES-1"> 
<entity schemes" http: //am holaasredgistret 
<period> 
<startDate>2013-01-01</startDate> 
<endDate>2013-12-31</endNate> 
</period> 
</gsontext> 
<ontext id="RESO"> 
<entity scheme="htto://wwew., holadsredistreb.sen 
<period> 
<startDate>2014-01-01</startDakte> 
<endDate>2014-12-31</endNDakte> 


</period> 
</context> 


<Nettnoomsattning ... ContextRef="RES0">3230700</Nettoomsattning> 


sel>AB Bygg</entity> 


<AktiveratArbete ... contextRef="RES0">209000</AktiverataArbete> 

<Nettoomsattning ... contextRef="RES-1">2822000</Nettoomsattning> 

<AktiveratArbete ... contextRef="RES-1">198500</aktiverataArbete> 
</xbx1> 


Resultaträkning i formatet XBRL 
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#FORMAT PC8 

#SIETYP 1 

#ORGNR 5566440000 

#FNAMN ""”verby F”retagsby AB" 


#RAR 0 20130101 20131231 
#RAR -1 20120101 20121231 
#UB 0 1210 13360 

#UB 0 1220 121754.55 


#UB -1 1229 -73815 
#UB -1 1242 -8085 


#RES 0 3040 -1619620.4 


#RES -1 3041 -498729 


#RES 0 3520 -2054 


#RES 0 3610 -487077 
Samma metadata 
Annan syntax 


Saldorapport i formatet SIE 


I XBRL-filen kopplas raderna i en resultaträkning till en period via attributet 
contextRef. | SIE-filen anges ett räkenskapsårs datum på raden som in- 
leds med #RAR med tillägget o för innevarande år och -1 för föregående 
år. Raderna som inleds med #RES kopplar respektive räkenskapsår till konto 
och belopp i de åtföljande kolumnerna. (#UB står för utgående balans.) 


Detta visar att metadata objektsmässigt är exakt likadant strukturerade 
i båda dokumenttyperna, men med olika syntax (tecken mellan skilda data 
och metadata). 


Slutsats: XBRL går att använda för saldorapporter, förutsatt en given kon- 
toplanstaxonomi i standarden XBRL. Därmed kan XBRL avändas för 
samtliga dokument i dataflödet efter konteringen. Övriga nordiska länder 
behöver alltså inte använda sig av SIE i saldorapporterna. 


Flödet (med format inom parentes) ser då ut som följer: 


Transaktion => Kontering => Saldorapport => Slutlig rapport 
(UBL) (Okänt format) (SIE eller XBRL) (iXBRL) 


Var definieras metadata? 


Rätt format räcker dock inte för att entydigt definiera dataflödet. Någonstans 
i dataflödet måste metadata/begrepp vara definierade för hela infrastruktu- 
ren, för att man ska kunna ta ut meningsfulla data ur flödet. (Till beloppet 
130 760 måste t.ex. kopplas "Råvaror och förnödenheter", valutan "SEK", 
perioden 2018-01-01--12-31 m.m. för att siffran ska bli meningsfull.) 
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Metadata i de slutliga rapporterna? 


I Australien samlade man begrepp (ca 9600 st) från samtliga myndighets- 
rapporter och lyckades via ett omfattande harmoniseringsförfarande banta 
ner antalet till 2800 st (med 71 %). I Nederländerna gjordes ett liknande 
harmoniseringsarbete, men där man inte kunde komma överens, lades 
begreppen i olika namnrymder. 


Metadata definierade utifrån myndighetsrapporterna har den svagheten att 
de mottagare som har andra begrepp/profiler i sina databaser än de offent- 
liga begreppen, t.ex. banker, försäkringsbolag och kreditinstitut, måste hålla 
sig till myndighetsbegreppen. Annars måste dessa organisationers nya 
begrepp definieras i varje plattform. (Plattformsföretagen kan inte i förväg 
förutse vilka de nya begreppen blir.) Mycket talar därför för att metadata 
inte ska låsas i myndighetsrapporterna. Dessutom måste då mjukvaruföretag 
manuellt koppla alla konton från varje kontoplan till varje rapport. 


Metadata från konteringen? 


Ska metadata (begreppen) definieras i kontona, dvs en standardiserad 
kontoplan? 


Företagen är skyldiga att föra bok, dvs hantera kontering. I bokföringen 
måste under alla förhållanden kontobegreppen definieras. Vad finns 
det för skäl att här definiera begrepp, som man senare inte kommer att an- 
vända? Vad finns det för skäl att definiera kontobegrepp som inte är jämför- 
bara med de kontobegrepp som definieras för andra företag? Stora fördelar 
finns vid fusioner och annat finansiellt samarbete eller vid jämförelse mellan 
företag att använda gemensamma kontobegrepp. 


Eftersom mjukvaruföretagens plattformar måste kunna anpassas till olika 
kontoplaner, framför allt i länder med en mängd olika kontoplaner, bör de 
enkelt kunna ta emot en standardkontoplan och vidare att kunna göra 
mappningar mot den. 


Hur förs metadata vidare från en standardkontoplan i XBRL till de 
slutliga rapporterna? 


Summeringen från kontona i saldorapporten byggd på en standardkontoplan 
till raderna i mottagarrapporten genereras med calculation linkbase i stället 
för som idag med reference linkbase. Därmed kan rapporterna genereras 
automatiskt (M2M, machine to machine). Observera att rapportraderna blir 
exakt definierade i förhållande till kontoplanen. Några kompromisser för 
radbegreppen som t.ex. i Australien behöver inte göras. Vill en rapportmot- 
tagare exkludera eller lägga till konton relativt myndigheterna till sina begrepp 
i sin taxonomi, går det utmärkt lätt. 
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Men kan man göra summeringar mellan olika taxonomier? I dagens taxono- 
mier sker summeringar enbart mellan raderna inom en rapport. Locator- 
elementet (<loc>) i calculation linkbase har enligt XBRL-standarden ett href- 
attribut, som pekar på definitionen i taxonomischemat. Attributet har dataty- 
pen anyURI dvs den kan peka på vilken som helst adress på internet. Det 
här öppnar även för branschkontoplaner. 


Allt talar därför för en standardiserad kontoplan, i första hand anpassad så 
att myndighetskraven uppfylls, men som bör vara så diversifierad att även 
andra rapportmottagare kan skapa egna begrepp utifrån summeringar av 
BAS-konton. 


Hur gör mjukvaruföretag som har en annan kontoplan än den som är stan- 
dard? De får göra mappningar mellan den egna och standardkontoplanen. 
Denna mappning behöver programmässigt bara göras en gång oberoende 
av hur många olika rapporter som sedan ska levereras. 


Slutligen innebär en standardkontoplan i XBRL och calculation linkbases 
som kopplar konton till rader i mottagarrapporterna att mjukvaruföretagen 
slipper att mappa konto för konto till rätt rad i sina rapportgeneratorer. 
Mappningen automatiseras och därmed försvinner en felkälla. Det innebär 
också att rapportmottagaren definierar och kan ta fullt ansvar för sina 
summeringar från standardkontoplanen. 


Frågan om noder för att ta emot rapporter (vart ska rapporter skickas?) 


Frågan om mottagarnoder löses genom att man i taxonomierna (i common- 
data-delen) standardmässigt har metadata för den adress till vilken rapporten 
ska skickas. Därmed skickas rapporten i plattformarnas standardmässiga 
hantering med automatik till rätt adress. 


Genom detta förfarande slipper myndigheterna också att bygga gemen- 
samma noder från vilka olika data senare ska distribueras till varje myndig- 
het. Den s.k. tekniken med "all in" eller "one stop shop" blir onödigt kompli- 
cerad. Varje rapportmottagare får enligt tekniken med hantering av motta- 
garadresser exakt de data den önskar i enlighet med sin taxonomi och sina 
calculation linkbases skickade direkt till mottagarens adress. Rapporteringen 
med standarden iXBRL innebär att rapporterna är läsbara och kan signeras 
samtidigt som de direkt kan lagras ned i mottagarens databaser. Med dagens 
teknik blir då nedladdningen i mottagarens databas elementär. 


Återstår att göra kopplingen transaktion => kontering. 


I UBL-standarden finns utrymme för att ange hur UBL-transaktionen ska 
konteras. Om det finns flera alternativ till kontering, kan transaktionen inne- 
hålla dessa. Då får användaren av plattformen välja rätt konto av de före- 
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slagna kontona. Annars, med ett föreslaget konto, kan kontering ske auto- 
matiskt. 


Sammanfattning 


Med ovanstående infrastruktur kommer programmeringstiden för mjukvaru- 
företagen att göra färdiga rapporter att minska med minst 90 %. APler kan 
användas för att generera färdig iXBRL-kod i stället för att manuellt göra 
kopplingar mellan konton och rapportrader. Snabba rapporter till nya motta- 
gare skapas enkelt via XBRLs APler. En infrastruktur med snabb och korrekt 
rapportering utifrån konteringen möjliggörs därmed. 


Summerat torde detta kunna vara en god start för utveckling av Nordic 
Smart Business. 


Erik Mjöberg | 
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